Repository navigation
transpose notes in cycles with target 't' using signed integers - #114
unlessgames wants to merge 17 commits into
Conversation
optionally glides an existing note to the specified target pitch instead of starting a new note
- run previous sequences for an entire pattern length or up to 4 steps to look past possible glided notes - memorize time where a note *will* stop so note glides can check if a note is playing or will be stopped
... and update samples to next phrase when time bases change
... it's already exported in the prelude and is necessary in order to create completely custom or fallback patterns
- build with `fwasm-exceptions` to fix build errors with recent rustc/emscripten compilers - update lua-src-rs accordingly
* separate cycle tests * variable values & targets in cycle * inject `Parameter` values into `Cycle` as vars, parsing enum strings as "sub-cycle" expressions * perf tweaks
* allow specifying user variables (static tables or functions) in cycles via a new `var` property * add API defs and examples Co-authored-by: Eduard Müller <mail@emuell.net>
* add step_time and iteration to map context * simplify lua callback error handling
Benchmark for f9cab99Click to view benchmark
|
|
Looks straight-forward so far. I'll give that an in depth try tomorrow.
Same with glide, where Have you considered allowing/using floating point numbers for transpose, which also allow fractional tuning? Then we could at least also use the same ugly floating point number syntax here instead of the + prefix. Using, or at least reserving, |
So currently floating point number are allowed and the values kept as-is, this signed integer notation is an addition to the current syntax of all targets, not a different case just for I think restricting to only be able to use floats in the syntax for the singular case is worse than having to add It would be great to have fractional tuning but I assumed that is out of scope since the
Sure, I'll push my wip branch soon so it is easier to discuss. |
This branch has not been deployed
2 participants
A draft for #93
Adding a new allowed target type in cycles using
tthat is used in the emitter to transpose the underlying note before output.It seems to work well and opens up some nice techniques around transposing patterns across time with alternating values etc.
A couple of things that are kinda off with this:
t1could just be a name, I opted for only allowing signed integers in the short form, soa:t+1is a valid transpose buta:t1is not. When using patterns for the target like[a b c]:t=<0 1 2 3>, they don't have to be signed.NamedFloat, not a new "NamedInt", I guess this is a bit misleading but probably fine and keeps the code simpler.[[a b c]:t=<0 7 12>]:t=<0 3>, where the two offsets would get added together instead of the<0 3>part being discarded. For a generalized syntax something like:t+=...could work, this might also be nice for other properties like volume etc.As an alternative to all this, I've experimented with a more generic way to allow for transposition inside the cycle (instead of leaving it for the emitter like in this PR). This isn't ready for testing yet, but still relevant here. In theory it would allow us to define operators to combine patterns, like
[a b c] &+ <0 1 2>where
&would be a prefix for all existing operators and&+would just be a generic addition that would work on constant types inside a cycle, sonote + numberornote + notewould be a transposition, butnumber + numberwould be a regular addition (so you could generate number streams for anything like[a b c]:t=[<0 1 2> &+ <12 24 -12>]).This might be a good way to leave an escape hatch in the syntax for all sorts of numeric operations and even other functionality like
[a b c d] &swing 0.3.Bringing this up because the simpler transposition implemented here overlaps with such plans and it might be better to only have one way to transpose notes.